Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-107.txt

Text File | 1994-12-08 | 43.5 KB | 1,179 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 09 Jun 92       Volume 1 : Issue 107

Today's Topics:

    Color WDEF's???
    ThinkC


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Christopher S. Eplett)
Subject: Color WDEF's???
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Wed, 22 Apr 1992 19:09:50 GMT

Hello out there,

    I have just entered into the world of WDEF's and have been
    successful implementing a B&W WDEF, but have been having problems
    working with the WMgrCPort ( or whatever... )

    Could somone point me to some sample color WDEF code that shows
    me how to do this sort of thing correctly? IM V is woefully
    terse on this particular topic... :)

        Thanks in advance,
        Christopher Hoek Eplett
        [e-mail]

    "We are flesh and blood! Not Wax!"  - Commander Hoek, Ren & Stimpy

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Wed, 22 Apr 1992 21:19:36 GMT

[e-mail] (Christopher S. Eplett) writes:

>Hello out there,

>    I have just entered into the world of WDEF's and have been
>    successful implementing a B&W WDEF, but have been having problems
>    working with the WMgrCPort ( or whatever... )

>    Could somone point me to some sample color WDEF code that shows
>    me how to do this sort of thing correctly? IM V is woefully
>    terse on this particular topic... :)

Apple makes the source code to their WDEFs/CDEFs available on their ftp server.
There is also pascal code doing a colod CDEf in a snippet, and maybe more source
on the developer's CDs. I believe also that the NeXT WDEF came with source
(well, that's b&w, but there was a color version, and the source for that may
also be around).

Sorry I can't be more specific as to locations, developer CDs and ftp.apple.com
are pretty large to search through. I once had the source for every *DEF I could
find, I don't know why, but tossed it all recently.

Alas, a grep of wuarchive's info-mac shadow doesn't show the NeXT WDEF. I don't
know where you'd find it.
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 1 May 92 19:48:34 GMT
Organization: Apple Co.

In article <mlanett.703977576@void>, [e-mail] (Mark Lanett) writes:
>
> Apple makes the source code to their WDEFs/CDEFs available on their ftp server.

Wrong.  Apple makes a "sample" WDEF available.  It is not the real one but a
completely functional duplicate.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 3 May 92 22:17:45 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
>
> In article <mlanett.703977576@void>, [e-mail] (Mark Lanett)
writes:
> >
> > Apple makes the source code to their WDEFs/CDEFs available on their ftp
server.
>
> Wrong.  Apple makes a "sample" WDEF available.  It is not the real one but a
> completely functional duplicate.

It's the 6.0.x version - and yes we should clean up the 7.0.x one for
distribution.
I've taken a note about this.

Cheers,
Kent/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 4 May 92 19:26:31 GMT
Organization: University of Illinois at Urbana

[e-mail] (Jon Pugh) writes:

>Wrong.  Apple makes a "sample" WDEF available.  It is not the real one but a
>completely functional duplicate.

Not the real one but a completely functional duplicate? Lesse, if the duplicate
wan't functional, wouldn't that have some implications for the "real" one? :-)
Or, how is a duplicate less real? (Ok, ok, I'll shut up).
- --
Mark Lanett, NCSA Software Development - [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 8 May 92 20:04:40 GMT
Organization: Apple Co.

In article <mlanett.705007591@void>, [e-mail] (Mark Lanett) writes:
>
> [e-mail] (Jon Pugh) writes:
>
> >Wrong.  Apple makes a "sample" WDEF available.  It is not the real one but a
> >completely functional duplicate.
>
> Not the real one but a completely functional duplicate? Lesse, if the duplicate
> wan't functional, wouldn't that have some implications for the "real" one? :-)
> Or, how is a duplicate less real? (Ok, ok, I'll shut up).


I lied.  It's not completely functional.  I also understand that the b&w
sample is the "actual" sys6 WDEF.  But what do I know?  I'm just blowing
smoke.

Jon

---------------------------

From: [e-mail] (               )
Subject: ThinkC
Date: 18 Mar 92 16:27:37 GMT
Organization: University of Waterloo

Hi there!

I have some simple questions regarding to programming languages for the
Macintosh PowerBook 170.

* Is there any Prolog or Lisp available for such machine.

* What is the different between ANSI-C and ThinkC?
  (If I want to do my assignments under ThinkC and then transfer the file
   to the UNIX machine in the university and compile the code under the
   gcc command, will there be any problem?)

* In sum, are there any compilers for Prolog, Lisp and C on the Mac that
   are fully compatitable to each other.?

*  BTW, does anybody out ther have any experience  with A/UX?


Thanks...

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 23 Mar 92 06:39:02 GMT
Organization: Florida Tech, CP/EE Dept.

Is there an InterNet ThinkC help guide out ther somewhere
for newbies? Tips like CDirector objects have their own
Cwindow instance (am I using the correct terminlogy) and
you don't have to waste time making a Cwindow object for
it? (Which I spent about an hour before I found out.)

Anyone?


- --
 The Evil Tofu


+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 23 Mar 92 06:42:10 GMT
Organization: Florida Tech, CP/EE Dept.

Does anyone have any suggestions on how
File Transfer Protocols ought to be implemented
as Think C Classes? I think it's easier than
trying to write file transfer tools.

Should this class insert a chore into a CApplications
assignidlechore list?


- --
 The Evil Tofu


+++++++++++++++++++++++++++

From: [e-mail] (carl m benda)
Date: 16 Apr 92 21:59:23 GMT
Organization: University of NC at Charlotte

I am having major dificulties trying to run a small program
which does file I/o Using standard C function calls.. in
particular fputc gives me a "bus error" inside ANSI-small
when running the code under System 7.0.. Any clues..

Much thanks for any direct response to me!
[e-mail]

/Carl

+++++++++++++++++++++++++++

From: [e-mail] (Homayoon Akhiani)
Organization: Digital Equipment Corporation
Date: Tue, 21 Apr 1992 23:12:49 GMT



I have the following piece of code, running on IIsi w/ Sys7 Tuneup 1.1.1
using ThinkC (I got it last month so I assume it is the lastest version)

malloc is not returning NULL, However when I step through the code with the
debugger, for both L and m, malloc returns some number like 0xFFFFF***

When I do examine (in the ThinkC debugger) *m or *L I get "Bus Error"

If I use "GO" the program will halted in the for loop (accessing L[0])
with bus error.

Is there a bug in malloc in ThinkC?


#define MSIZE   10000
unsigned int    *m;
char            **L;
 m = (unsigned *)malloc((unsigned)MSIZE*sizeof(unsigned int));
 assert(m!=NULL);
 L = (char **)malloc((unsigned)MSIZE*sizeof(char *));
 assert(L!=NULL);
 for(i=0;i<MSIZE;i++) L[i]=NULL;



- -------------------------------------------------------------------------------
Homayoon Akhiani                               "Turning Ideas into ... Reality"
Digital Equipment Corporation                        "Alpha, The New Beginning"
77 Reed Rd. Hudson, MA 01701            "All Rights Reserved. Copyright(c)1992"
Email: [e-mail]        "It is me speaking, not my company"
- -------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Mike Bell)
Date: 23 Apr 92 19:18:10 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Homayoon Akhiani) writes:
> Path:
>
apple!constellation!munnari.oz.au!mips!decwrl!deccrl!news.crl.dec.com!hollie.r
dg.dec.co
> m!ryn.mro4.dec.com!ricks.enet.dec.com!akhiani
> From: [e-mail] (Homayoon Akhiani)
> Newsgroups: comp.sys.mac.programmer
> Subject: ThinkC and malloc problem
> Message-ID: <[e-mail]>
> Date: 21 Apr 92 23:12:49 GMT
> Sender: [e-mail] (USENET News System)
> Reply-To: [e-mail] (Homayoon Akhiani)
> Organization: Digital Equipment Corporation
> Lines: 33
>
>
>
> I have the following piece of code, running on IIsi w/ Sys7 Tuneup 1.1.1
> using ThinkC (I got it last month so I assume it is the lastest version)
>
> malloc is not returning NULL, However when I step through the code with the
> debugger, for both L and m, malloc returns some number like 0xFFFFF***
>
> When I do examine (in the ThinkC debugger) *m or *L I get "Bus Error"
>
> If I use "GO" the program will halted in the for loop (accessing L[0])
> with bus error.
>
> Is there a bug in malloc in ThinkC?
>
>
> #define MSIZE   10000
> unsigned int    *m;
> char            **L;
>  m = (unsigned *)malloc((unsigned)MSIZE*sizeof(unsigned int));
>  assert(m!=NULL);
>  L = (char **)malloc((unsigned)MSIZE*sizeof(char *));
>  assert(L!=NULL);
>  for(i=0;i<MSIZE;i++) L[i]=NULL;
>
>
>
> ----------------------------------------------------------------------------
- ---
> Homayoon Akhiani                               "Turning Ideas into ...
Reality"
> Digital Equipment Corporation                        "Alpha, The New
Beginning"
> 77 Reed Rd. Hudson, MA 01701            "All Rights Reserved.
Copyright(c)1992"
> Email: [e-mail]        "It is me speaking, not my company"
> ----------------------------------------------------------------------------
- ---



If you don't include the header <stdlib.h> in your program, it will still
compile, but malloc will behave just as you describe. It passes back a non-
zero (but garbage) pointer, that then bus errors. It is mentioned in the
manual, but it still seems like weird behavior to me.



   -Mike




*****************************************

Mike Bell                                            email: [e-mail]
68000 High Performance Software Group
MS 60-CS
Apple Computer, Inc.
20525 Mariani Ave.
Cupertino, CA 95014

*****************************************

+++++++++++++++++++++++++++

From: [e-mail] (Jonathan Kimmitt)
Date: 24 Apr 92 12:45:26 GMT
Organization: Cambridge Consultants Ltd., Cambridge, UK

>> I have the following piece of code, running on IIsi w/ Sys7 Tuneup 1.1.1
>> using ThinkC (I got it last month so I assume it is the lastest version)
>>
>> malloc is not returning NULL, However when I step through the code with the
>> debugger, for both L and m, malloc returns some number like 0xFFFFF***
>>
>> When I do examine (in the ThinkC debugger) *m or *L I get "Bus Error"
>>
>> If I use "GO" the program will halted in the for loop (accessing L[0])
>> with bus error.
>>
>> Is there a bug in malloc in ThinkC?
>>
>If you don't include the header <stdlib.h> in your program, it will still
>compile, but malloc will behave just as you describe. It passes back a non-
>zero (but garbage) pointer, that then bus errors. It is mentioned in the
>manual, but it still seems like weird behavior to me.

- --- end include text ---

One of the most annoying (and non-portable) features of C is that
unprototyped functions will default to int for all input and output
parameters. The size of int is not defined but is usually 32 bits on
workstations and 16 bits for most PC implementations, and for THINK_C
However pointers for a 68000 will be 32 bits whatever.
This means code running on a 32 bit workstation will work passing
pointers to subroutines without declaring the parameters of those functions
unfortunately THINK_C will not work because it will assume 16 bits is
passed to malloc if not declared to take a size_t (=pointer size (=32 bits))
parameter.The compiler will also need to know that malloc is supposed
to return a void *, otherwise it will assume an integer(16 bits)

The moral of this is dont expect any C program to work in THINK C
unless you have checked 'check pointer types' and 'require prototypes'
in your preferences section. This will prevent successful compilation
if all required header files are not present.

If you port a program from unix you will probably find any
%d and %x statements in printf and scanf statements
will need to be changed to %ld and %lx
and occurences of int will need to be changed to long int
where necessary.

The compiler will not warn you if args to printf/scanf are the wrong size

to test portability of a program or lack of it using gnu-c
you can use gcc -mshort -Wall
this will generally cause the compilation to fail and or the executable not to
work, unless carefully written

Things would be nuch nicer if THINK C understood that an int is assumed
to be 32 bits by most programmers, whatever the natural size of 68000
code ought to be ...

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Fri, 24 Apr 92 14:02:42 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Jonathan Kimmitt) writes:

>If you port a program from unix you will probably find any
>%d and %x statements in printf and scanf statements
>will need to be changed to %ld and %lx
>and occurences of int will need to be changed to long int
>where necessary.

>
>Things would be nuch nicer if THINK C understood that an int is assumed
>to be 32 bits by most programmers, whatever the natural size of 68000
>code ought to be ...

Use THINK C 5.0.x-- it allows either 2-byte or 4-byte ints--
programmers choice.

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 24 Apr 92 15:43:54 GMT
Organization: Symantec Corp.

>>>>> On 24 Apr 92 12:45:26 GMT, [e-mail] (Jonathan Kimmitt) said:

 > Things would be nuch nicer if THINK C understood that an int is
 > assumed to be 32 bits by most programmers, whatever the natural
 > size of 68000 code ought to be ...

In C 5.0, there's a compiler option that makes the int type 32 bits
wide. It's called "4-byte ints", and it's described on p. 193 in the
section entitled "Porting Code to THINK C".

If you're using ANSI, you must recompile it with the 4-byte ints
option on as well. This will let you format your 32 bit ints using %d,
etc.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Fri, 24 Apr 92 15:57:55 GMT

In article <[e-mail]> [e-mail] (Jonathan Kimmitt) writes:
>
(stuff about 32-bit pointers removed)...
>
>Things would be nuch nicer if THINK C understood that an int is assumed
>to be 32 bits by most programmers, whatever the natural size of 68000
>code ought to be ...

This is a generic problem with C and has been pretty well addressed by the
changes to ANSI. Of course, it is still up to the developer to write portable
code. Apple and THINK have worked to remove the incompatibilites between
their compilers, and Toolbox routines are no longer declared to use the "int"
type, since it is ambiguous. They use "short" and "long" instead.

Writing portable code is difficult. For a good example of how difficult, take
a look at the book _The_C_Standard_Library_ by, I believe, Plauger (my book
is at home). The code is a good object lesson in how difficult it is.

The "natural size" for a 68000 is sort of ambiguous. Does one go with the
register size, 32 bits, or with the size of the data bus on the original
68000? On a 68000, MOVE.W is quicker than MOVE.L, but on a machine with
a 32-bit data bus (most of the Mac II line) they are (I believe) equivalent
in speed. THINK took one approach, MPW the other. THINK has now been
modified so that all the libraries can be built using 32-bit or 16-bit ints,
and works either way. The upshot of this all is that it works now, and code
is very easily transported between MPW and THINK.

I don't know about most programmers, but I think it is kind of unfair to
say that "int" is generally thought of as 32-bits. All K&R and ANSI say is
that it falls within a certain range compared to the other types. If
programmers are making assumptions about the integer size which are non-
portable, they are writing non-portable code.

I don't want to turn this into a war, I just thought I'd throw my two cents
in. Even the best of us wind up writing non-portable code at times (often
there is no good alternative). However, never using "int" helps.
Your suggestions for requiring prototypes, etc. will also help.

- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Michael Harpe)
Organization: University of Louisville
Date: Fri, 24 Apr 1992 18:55:16 GMT

[e-mail] (Jonathan Kimmitt) writes:

>One of the most annoying (and non-portable) features of C is that
>unprototyped functions will default to int for all input and output
>parameters. The size of int is not defined but is usually 32 bits on
>workstations and 16 bits for most PC implementations, and for THINK_C
>However pointers for a 68000 will be 32 bits whatever.
>This means code running on a 32 bit workstation will work passing
>pointers to subroutines without declaring the parameters of those functions
>unfortunately THINK_C will not work because it will assume 16 bits is
>passed to malloc if not declared to take a size_t (=pointer size (=32 bits))
>parameter.The compiler will also need to know that malloc is supposed
>to return a void *, otherwise it will assume an integer(16 bits)

THANK YOU!  Now I know i'm not crazy.  I had a similar type of problem a couple
of weeks ago.  People told me I just didn't understand C well enough.  I
thought it was behaving differently on the Mac....

>If you port a program from unix you will probably find any
>%d and %x statements in printf and scanf statements
>will need to be changed to %ld and %lx
>and occurences of int will need to be changed to long int
>where necessary.

>The compiler will not warn you if args to printf/scanf are the wrong size

I had this exact problem and I did what this poster described.  That did
indeed fix what I was porting.  I think the compiler SHOULD warn you!

>to test portability of a program or lack of it using gnu-c
>you can use gcc -mshort -Wall
>this will generally cause the compilation to fail and or the executable not to
>work, unless carefully written

>Things would be nuch nicer if THINK C understood that an int is assumed
>to be 32 bits by most programmers, whatever the natural size of 68000
>code ought to be ...

Hear, Hear!


- --
- ---------------------------------------
"I will not barf unless i'm sick"
                                   - A Chalkboard from "The Simpsons"


+++++++++++++++++++++++++++

From: [e-mail] (Russell S. Finn)
Organization: MIT Laboratory for Computer Science
Date: Fri, 24 Apr 1992 22:12:24 GMT

In article <[e-mail]>, [e-mail] (Michael Harpe) writes:
|> [e-mail] (Jonathan Kimmitt) writes:
|> >If you port a program from unix you will probably find any %d and
|> >%x statements in printf and scanf statements will need to be
|> >changed to %ld and %lx and occurences of int will need to be
|> >changed to long int where necessary.
|>
|> >The compiler will not warn you if args to printf/scanf are the wrong size
|>
|> I had this exact problem and I did what this poster described.  That did
|> indeed fix what I was porting.  I think the compiler SHOULD warn you!

In general, the compiler *can't* warn you about this.  Whether or not
you think it's appropriate for the compiler, given:

    void foo (void)
    {
        long n = 17L;
        printf ("n = %d", n);
        }

to scan the string "n = %d" and determine that since the first
parameter replacement string calls for an "int", but the first
argument is a "long", it should generate an error (and personally I
think that's inappropriate), consider the following case:

    void foo (char *s)
    {
        long n = 17L;
        printf (s, n);
        }

This is certainly legal and meaningful C code, but there's no way the
compiler can check this.  (Of course, it *could* emit code to
dynamically check the arguments at run-time -- not in *my* C compiler,
thank you.)

On the other hand, the alternative, seen in languages like Modula-2,
is to require a separate procedure call for each item to be output, so
that typechecking may be done (along the lines of "WriteString (s);
WriteLong (n);" etc.  You buys your compiler and you takes your
choice.

Typechecking arguments for functions, when the type and number of
their parameters have not been previously declared (as with "printf"),
is a problem which has not been solved by any programming language I'm
aware of.

- -- Russell S. Finn
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 25 Apr 92 02:43:05 GMT
Organization: Taligent

>
> [e-mail] (Jonathan Kimmitt) writes:
>
> >Things would be nuch nicer if THINK C understood that an int is assumed
> >to be 32 bits by most programmers, whatever the natural size of 68000
> >code ought to be ...
>

I spent last Christmas vacation doing a close analysis of code generated by
THINK C, MPW C, and GNU C. MPW was about 10% better than GNU because GNU didn't
optimize long branches into short branches. THINK was about 10% better than MPW
because it used 16-bit ints instead of 32-bit ints. THINK code runs a little
faster, too, because you can use 680x0 instructions for math instead of library
routines. So using 16-bit integers is definitely a win.

Personally, I don't think that most C programmers assume an int is the same as a
long. *I* don't, and I know that everyone I work with is drilled to not make
that mistake, either. Anyone who _does_ make that assumption is quickly burnt.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 22:59:42 GMT
Organization: MacDTS Mongols

> In article <[e-mail]> [e-mail] (Jonathan Kimmitt)
writes:
> >
> (stuff about 32-bit pointers removed)...
> >
> >Things would be nuch nicer if THINK C understood that an int is assumed
> >to be 32 bits by most programmers, whatever the natural size of 68000
> >code ought to be ...

Argh, who assumes what about ints, they could be anything between an 8-bit
micro and a Cray? I never use ints, nope, (un)signed longs and shorts are
the way to go, even better, typecast everything so it's easier to port
code.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 27 Apr 92 02:55:33 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> > In article <[e-mail]> [e-mail] (Jonathan Kimmitt)
> writes:
> > >
> > (stuff about 32-bit pointers removed)...
> > >
> > >Things would be nuch nicer if THINK C understood that an int is assumed
> > >to be 32 bits by most programmers, whatever the natural size of 68000
> > >code ought to be ...
>
> Argh, who assumes what about ints, they could be anything between an 8-bit
> micro and a Cray? I never use ints, nope, (un)signed longs and shorts are
> the way to go, even better, typecast everything so it's easier to port
> code.

Actually, someone might ask, int:s are the most optimal non-floating
variable structure that the compilers generate, why not make use of this?

My answer, I rather spend less time with porting, than thinking about
performance in code in the initial stage - without even knowing about
the real bottlenecks.

I hope this explained my point of view.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Jonathan Kimmitt)
Date: 27 Apr 92 13:22:24 GMT
Organization: Cambridge Consultants Ltd., Cambridge, UK

[e-mail] (Kent Sandvik) writes:

>Argh, who assumes what about ints, they could be anything between an 8-bit
>micro and a Cray? I never use ints, nope, (un)signed longs and shorts are
>the way to go, even better, typecast everything so it's easier to port
>code.

I assume our correspondent means by typecasting, typedefining code such as

typedef unsigned long ul_t;

rather than

ptr = (char *)malloc((long) bytes);

where the casts (char *) and (long) are definitely not an increase
in portability.

This was not a declaration of war, nor have I anything against Symantec
whose products I find easy to use.
I was simply saying that one of the defects of the language C itself
is that the default type for parameters and returns for undeclared functions
is the nebulous quantity called int which is the natural size of the machine
for arithmetic etc. and is usually 16 bits or more.
In the days when 64K was a lot, Kernighan & Ritchie would never have imagined
that a range of machines would arise
with more addressing range than the machines natural word length.
However this is exactly what has happened with Intel's range of processors
and 680X0 compilers that assume int to be 16 bits for the sake of efficiency
and ANSI-C addresses the issue with its size_t type.
There is a large body of C code that was originally written for
non-ansi compilers which does make the assumption that an int can
contain a pointer, and if it is desired to make any use of such code
it is useful to be able to force your favourite compiler to use an
appropriately large int, and I am glad to be told that THINK C 5.0.X
addresses this issue. If you can't afford the upgrade and don't want the
fag of the 'require prototypes' option, you could change the name of
malloc in the ANSI library to malloc_ and in <stdlib.h> add the line
#define malloc malloc_
this would cause your compilation to fail if <stdlib.h> is not
included everywhere where it is needed. This is the kind of approach adopted
in <console.h> and if applied to the whole ANSI library it would have
caused irritation to some users but would have saved many others from
compiling programs with incorrect library call parameters.
Life would be even easier for beginners and hands on first/ read manual later
users if the ANSI function headers were included by default in a similar
way to the precompiled <MacHeaders> file, but we might run the risk of
dispelling the mystique that surrounds the C programming community ...

+++++++++++++++++++++++++++

From: [e-mail] (Mike Webb)
Date: 27 Apr 92 14:12:47 GMT
Organization: Schlumberger Technologies CAD/CAM Division


     Speaking of odd things with THINKC's (5.0x) compiler settings...

     Has anyone else run into a problem with the member function from
     OOPSDEBUG going into an (apparently) infinite loop?  This is
     definitely compiler option related.  Yesterday, I was working on a
     numerically intensive OOP (i.e. one that should run about 5x faster
     with the 6888x option checked, but uses TCL to run the user interface),
     but member was semi-consistently going into an infinite loop.  In my
     code, member would always hang (before it got into the numerical code),
     but not always in the same place (depended on where breaks were set!).
     The options I was using were to the effect of:

     68881
     68020
     sizeof(int) == 4
     sizeof(double) == 8
     native mode floating point

     Re-compiling ANSI and OOPSDEBUG with these options did not help.
     Reseting the compiler settings to the "factory settings" made the
     program work, but meant I couldn't use 68881 :-(

     Probably the next step is to systematically figure out which compiler
     options cause the problem.

+++++++++++++++++++++++++++

From: [e-mail] (Michael R Bradshaw)
Date: 27 Apr 92 17:57:49 GMT
Organization: Massachusetts Institute of Technology

In article <[e-mail]>
[e-mail] (Mike Webb) writes:



    Speaking of odd things with THINKC's (5.0x) compiler settings...

    Has anyone else run into a problem with the member function from
    OOPSDEBUG going into an (apparently) infinite loop?  This is
    definitely compiler option related.  Yesterday, I was working on a
    numerically intensive OOP (... text deleted ...

    The options I was using were to the effect of:

    68881
    68020
    sizeof(int) == 4
    sizeof(double) == 8
    native mode floating point

    Re-compiling ANSI and OOPSDEBUG with these options did not help.
    Reseting the compiler settings to the "factory settings" made the
    program work, but meant I couldn't use 68881 :-(

    Probably the next step is to systematically figure out which compiler
    options cause the problem.

I too had this same problem a while back, but was only using the ANSI
library.  My code was also numerically intensive, and used malloc/free
to allocate temporary storage matrices. When I tried using the PROFILER
and various compinations of 68000/68020/68881 and native floating point
formats, my code would crash at apparently random places.

I am fairly certain that I didn't even come close to a low memory
situation or munge the malloc/free arguments and array indices.

Any other data points, or solutions out there?


- --
                    [e-mail]
                    Michael Bradshaw
                    "Home of the lame .sig file"

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 27 Apr 92 22:25:58 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company

In article <[e-mail]> [e-mail] (Jonathan Kimmitt) writes:
>Things would be nuch nicer if THINK C understood that an int is assumed
>to be 32 bits by most programmers, whatever the natural size of 68000
>code ought to be ...

Things would be nicer still if C programmers didn't assume any such
stupid thing, and would code right in the first place, using forward
declarators for function return values, longs instead of ints for things
that need to be larger than 16 bits, and typedefs for things that have
to be particular sizes (so they can be tuned in a machine-dependant
header file).  And these days, prototypes.  That way, we wouldn't be
having all this trouble in the first place, and we could still get
small, efficient code on smaller machines that would run no slower
on the bigger ones (unlike the other way around).

The biggest example of how to do this wrong was a few years ago when
I tried to get PISTOL (Portably Implemented Stack Oriented Language --
a FORTH-like language written in C) ported.  It was written on a 16-bit
int 16-bit pointer Z-80 platform, and I was trying to put it on a
16-bit int, 32-bit pointer 68000 system.  Yech.  It was the most non-
portable C code I'd ever seen.  Buried deeply within the code were
all sorts of assumptions:  that ints and pointers were the same size,
that said size was 16 bits, and that said entities were little-endian.
There were more.  I gave up.  It truly was that thing we've all heard
about:  assembly language code that happened to be written in C.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Homayoon Akhiani)
Date: 27 Apr 92 23:50:49 GMT
Organization: Digital Equipment Corporation


 Thanks for the replies.
 Adding stdlib.h and switching the compiler to 32 bit int's fixed the problem.

 Many of you ask me whay I am not using Newptr, Well, the code that I am trying
 to compile is suppose to be a portable one.
 It should be compile on many platforms. Newptr is Mac thingy.

 Now, I am fighting with fopen...
 basically, I trace the program to the fopen call and then the machine hangs!




+++++++++++++++++++++++++++

From: [e-mail] (Mike Webb)
Date: 28 Apr 92 16:05:17 GMT
Organization: Schlumberger Technologies CAD/CAM Division

In article <[e-mail]>, [e-mail] (Michael R Bradshaw) writes:
|>
|> ... Discussion of hangs and crashes in numerically intensive OOP
|> with random behavior relating to breakpoint setting, compiler
|> options, member, malloc, ANSI library, ... omitted
|>
|> Any other data points, or solutions out there?
|>

While not relating to my original problem (hangs in member), I have
run into various problems with the ANSI library as delivered by
Symantec with THINKC 5.x.  The two which "broke the camel's back"
were:

    1. [f,s]printf is essentially useless with [l]g, [l]f, [l]e
       format items (h format item is non-ANSI).

    2. Garbage results in return values of int and double from
       ANSI functions.

Both of these problems are corrected by recompiling the source for
ANSI with "useful" compiler options (e.g. 68020, 68881, native mode
floating point, ...).  Symantec is nice in that for some libraries,
they give you the source, so people can make their own ANSI lib that
uses their typical compiler options.

In addition, various people in comp.sys.mac.programmer have reported
problems with malloc.  For Mac purposes, I essentially don't use
malloc because of relocation problems when calls are made across
segments (remember, ANSI is c.28k bytes and usually gets stuck into
its own segment!).  Where I do use malloc, it is for *VERY* temporary
storage, that is not expected to persist to the next function call.
I have not had problems using malloc in this way, and use Handles for
data I need to keep around for any length of time.

Another big problem with malloc for numerical programming is that
many C compilers (including THINKC) won't malloc > 32K bytes of
space (that's 4K doubles - which is not enough for numerical analysis).
Typically, this fails by allocating 32K bytes and then allowing you
to overwrite memory beyond the end of the 32K bytes (which causes
bus errors if you're lucky and really strange behavior if your not).

                                        -- Mike Webb

+++++++++++++++++++++++++++

From: [e-mail] (Russell S. Finn)
Organization: MIT Laboratory for Computer Science
Date: Tue, 28 Apr 1992 20:16:38 GMT

In article <[e-mail]>, [e-mail] (Mike Webb) writes:
|> While not relating to my original problem (hangs in member), I have
|> run into various problems with the ANSI library as delivered by
|> Symantec with THINK C 5.x.  The two which "broke the camel's back"
|> were:
|>
|>     1. [f,s]printf is essentially useless with [l]g, [l]f, [l]e
|>        format items (h format item is non-ANSI).
|>
|>     2. Garbage results in return values of int and double from
|>        ANSI functions.
|>
|> Both of these problems are corrected by recompiling the source for
|> ANSI with "useful" compiler options (e.g. 68020, 68881, native mode
|> floating point, ...).  Symantec is nice in that for some libraries,
|> they give you the source, so people can make their own ANSI lib that
|> uses their typical compiler options.

At first, I was totally confused by this, but the reference to
recompiling ANSI suggests to me that you were probably trying to use
the supplied ANSI library, which uses 2-byte ints, with code that uses
4-byte ints, and that when you recompiled ANSI, you set the 4-byte int
option on -- which is exactly what the manual tells you to do in this
case.  I suspect that the compiler options you mention actually have
little to do with this (in fact, if you look at the ANSI source code,
you'll find it takes great pains to work correctly no matter what the
68881 settings are).

- -- Russell S. Finn
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mike Webb)
Date: 29 Apr 92 15:42:54 GMT
Organization: Schlumberger Technologies CAD/CAM Division

In article <[e-mail]>, [e-mail] (Russell S. Finn) writes:
|> (Text from original posts deleted...)
|>
|> At first, I was totally confused by this, but the reference to
|> recompiling ANSI suggests to me that you were probably trying to use
|> the supplied ANSI library, which uses 2-byte ints, with code that uses
|> 4-byte ints, and that when you recompiled ANSI, you set the 4-byte int
|> option on -- which is exactly what the manual tells you to do in this
|> case.  I suspect that the compiler options you mention actually have
|> little to do with this (in fact, if you look at the ANSI source code,
|> you'll find it takes great pains to work correctly no matter what the
|> 68881 settings are).
|>
|> -- Russell S. Finn
|> [e-mail]
|>

The anecdotes about re-compiling ANSI came from when I had just upgraded
from THINKC 4.x to THINKC 5.x.  In 4.x, different ANSI libs were supplied,
while 5.x supplies only one.  The 4.x project compiled, but showed the strange
behavior discussed (which sounded like alot of other THINKC 5.x problems
with ANSI functions that have been discussed on the net over the last few
weeks, and e-mail relating to this post).

The original thread is that with the indicated compiler options (specifically
4 byte ints, 68881, 8 byte doubles, native mode FP, 68020) the member
function (used in the bowels of TCL) goes into an infinite loop *EVEN AFTER* ANSI, OOPSDebug (contains member) were re-compiled.  Program only works when
"unacceptable" (read no 68881) compile options are used.  Also, "infinite loop" should probably be taken with a grain of salt.  I suspect it is really in a
for loop to O(2**31), but don't really have the patience to let the program prove this.  I suspect that this is a "int which should be short" problem in
TCL or some of the OOP RT support functions (e.g. member).  Why it only shows
up in one of my projects (which is very similar to others - read identical
at the OOP level) is mysterious.

                                               Mike Webb

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 2 May 92 04:16:22 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Mike Webb) writes:

   In addition, various people in comp.sys.mac.programmer have
   reported problems with malloc.

This is true, but none of these problems has been due to a bug in
malloc(). The code for malloc() hasn't been changed in 3 years, since
it was shipped with THINK C 4.0. I expect that all of the programmer
groups on Usenet see a lot of traffic regarding problems with dynamic
allocation (except the LISP ones, of course :-).

   For Mac purposes, I essentially don't use malloc because of
   relocation problems when calls are made across segments (remember,
   ANSI is c.28k bytes and usually gets stuck into its own segment!).

It sounds like you're confusing Mac segments with DOS segment
pointers. There isn't any problem with sharing malloc'd pointers
across Mac CODE segments.

The problem that you ran into originally is, I believe, caused by a
bug in the header file oops.h. When you compile with the 4-byte ints
option on, the Class ID parameter to member() is a short int. However,
member uses a varargs prototype, so this argument is widened to a
4-byte int. This can be fixed by modifying the oops.h header file by
replacing the line:

    char __member(...);

with the lines:

    #if !__option(int_4)
    char __member(...);
    #else
    char __member(void *, short);
    #endif

This is not an official fix, but it should work correctly.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ray Arachelian)
Date: 5 May 92 20:10:00 GMT
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY

On 04-25-92, [e-mail].E wrote to ALL:

 R> This is certainly legal and meaningful C code, but there's no way the
 R> compiler can check this.  (Of course, it *could* emit code to
 R> dynamically check the arguments at run-time -- not in *my* C
 R> compiler, thank you.)

You most certainly can do run time checking.  If you're using Think C,
check out the "Think C 5.0 Folder:C Libraries:sources:printf.c" file.
Just modify it to call sizeof() and check if they're longs or shorts or
what.

Of course you'll have to rewrite it to sprintf and fprintf, and you show
high objection to this, but the possibility is there.  It wouldn't be a
good idea to just report a run time error.  It would be a good idea to
check the size for a short, int, or long, and just change the way you deal
with %d's, etc.


 * Freddie 1.2b7 * You have been found guilty of commerce with the devil.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Ray Arachelian - Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 19:43:40 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Homayoon Akhiani) writes:
>
>
>  Thanks for the replies.
>  Adding stdlib.h and switching the compiler to 32 bit int's fixed the problem.
>
>  Many of you ask me whay I am not using Newptr, Well, the code that I am
trying
>  to compile is suppose to be a portable one.
>  It should be compile on many platforms. Newptr is Mac thingy.

Can't avoid it anyway, malloc calls NewPtr.

Cheers,
Kent

---------------------------

End of C.S.M.P. Digest
**********************